New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Removing deprecated call to Configuration::setSchemaAssetsFilter() + extendable #935
Conversation
$connectionFilters = []; | ||
foreach ($filters as $id => $tagAttributes) { | ||
foreach ($tagAttributes as $attributes) { | ||
$name = isset($attributes['connection']) ? $attributes['connection'] : $container->getParameter('doctrine.default_connection'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should ignoring the name apply it to the default connection, or to all connections ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was wondering about this too. Making it apply to all connections is actually more useful - as, for example, Symfony's session system could (in theory) say: "Hey, ignore a session
table that exits in any connection... I'm not sure which connection is used for the PDO instance I'm using".
But, that also seems like a possible, legitimate edge-case: I want to ignore session
on connection 1, but I really DO have a session
table on connection2 that I'm managing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with Ryan here: users should know which connection handles which tables and can build their ignore lists accordingly.
f724b13
to
40493af
Compare
Feedback handled! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've refrained from commenting on code style since I'll only be adding doctrine/coding-standard
in a future PR. There are a couple of changes I'd suggest making.
77ed9d6
to
1c41376
Compare
Updated and rebased! Thanks for checking it! |
Some tests still seem to fail: https://travis-ci.org/doctrine/DoctrineBundle/jobs/514116227#L347
|
1c41376
to
8049933
Compare
Sorry about that! It's better now - only php nightly failing for unrelated reasons. |
80a93e7
to
38d32c2
Compare
…ssion() ... and making the schema filter stuff a "plugin" system, which is the intention of the new way it's handled in doctrine/dbal
38d32c2
to
7c1d1da
Compare
I've rebased the branch on top of master to fix build the nightly build issue and fixed CS. Thanks for building this @weaverryan! |
Thanks @weaverryan! |
Hi!
If you're using doctrine/dbal 2.9 or higher, this removes the deprecated call to
Configuration:: setFilterSchemaAssetsExpression()
. It also makes the "schema filter" extendable via a tag. The use-case is when a 3rd-party bundle manages a table automatically for you through DBAL and you don't want, for example, Doctrine migrations (https://github.com/doctrine/migrations/blob/cf7f94b0bcfbd7d9c240aee759dc6619bc9ad796/lib/Doctrine/Migrations/Generator/DiffGenerator.php#L117) /doctrine:schema:update
to suggest removing that table because it's not found in the mapping metadata.One real-world use-case will be for #868: when the Doctrine transport is added to Messenger, a table will be created for storing messages (either automatically by Messenger or manually by the user - their choice). DoctrineBundle itself could use this hook to avoid migrations trying to remove that table once it's created.
Thanks!